1. Field of the Invention
The present invention relates to computer systems such as microprocessors. More specifically, the present invention relates to a software debug support system and operating method in processors.
2. Description of the Related Art
The growth in software complexity, in combination with increasing processor clock speeds, has placed an increasing burden on application software developers. The cost of developing and debugging new software products is now a significant factor in processor selection. A failure to include adequate software debug functionality in a processor results in longer customer development times and reduces attractiveness of the processor for use within industry. Software debug support is particularly useful in the embedded products industry, where specialized on-chip circuitry is often combined with a processor core.
The software debug tool configuration of a processor addresses the needs of several parties in addition to the software engineer who develops program code for execution on the processor. A "trace" algorithm developer searches through captured software trace data that reflects instruction execution flow in a processor. An in-circuit emulator developer deals with problems of signal synchronization, clock frequency and trace bandwidth. A processor manufacturer seeks a software debug tool solution that avoids an increased processor cost or design and development complexity.
In the desktop systems, complex multitasking operating systems are currently available to support software debugging. However, the initial task of getting the operating systems running reliably often calls for special development equipment While not standard in the desktop environment, development equipment such as logic analyzers, read-only memory (ROM) emulators, and in-circuit emulators (ICE) are sometimes used in the embedded industry. In-circuit emulators have some advantages over other debug environments including complete control and visibility over memory and register contents, and supplying overlay and trace memory if system memory is insufficient.
Traditional in-circuit emulators are used by interfacing a custom emulator back-end with a processor socket to allow communication between emulation equipment and the target system. The custom design of emulator interfaces in increasingly unrealistic and expensive as product life cycles are reduced and nonstandard and exotic integrated circuit packages are predominant in present day processor design.
Few known processor manufacturing techniques are available that include a suitable full-function in-circuit emulation functionality. Most processors in personal computer (PC) systems implement emulation functionality using a multiplexed approach in which existing pins are multiplexed for alternative use in a software debug application. Multiplexing of pins is not desirable in embedded controllers, which inherently suffer from overload of pin functionality.
Some advanced processors multiplex debug pins in time, for example by using the address bus to report software trace information during a Branch Target Address (BTA) cycle. The BTA-cycle is stolen from regular bus operation cycles. However in debug environments with high branch activity and low cache hit rates, BTA-cycles are often fully occupied handling branches, resulting in a conflict over access to the address bus that necessitates processor "throttle back" to prevent a loss of instruction trace information. For example, software in the communications industry is branch-intensive and suffers poor cache utilization often resulting in 20% or more throttle back, an unacceptable amount for embedded products which are subject to real-time constraints.
In another approach, a second "trace" or "slave" processor is combined with a main processor, with the two processors operating in-step. Only the main processor fetches instructions. The second, slave processor monitors fetched instructions on the data bus and maintains an internal state in synchronization with the main processor. The address bus of the slave processor supplies trace information. After power-up, via a JTAG (Joint Test Action Group) input, the second processor is switched into a slave mode of operation. The slave processor, freed from instruction fetch duties, uses the slave processor address bus and other pins to supply trace information.
Another existing debug strategy utilizes implementation of debug support into every processor in a system, but only bonding-out signal pins in a limited number of packages. The bond-out versions of the processor are used during debug and replaced with the smaller package for final production. The bond-out approach suffers from the need to support additional bond pad sites in all fabricated devices, a burden in small packages and pad limited designs, particularly if a substantial number of extra pins are required by the debug support variant. Furthermore, the debug capability of specially-packaged processors is unavailable in typical processor-based production systems.
In yet another approach, specifically the Background Debug Mode (BDM) implemented by Motorola, Inc., limited on-chip debug circuitry is implemented for basic run control. The BDM approach utilizes a dedicated serial link having additional pins and allows a debugger to start and stop the target system and apply basic code breakpoints by inserting special instructions in system memory. Once halted, special commands are used to inspect memory variables and register contents. The BDM system includes trace support, but not conveniently using the serial link. Instead the BDM system supplies trace support through additional dedicated pins and expensive external trace capture hardware that transfer instruction trace data.
Accordingly, present day techniques for software debugging suffer from a variety of limitations including increased packaging and development costs, circuit complexity, processor throttling, and bandwidth matching difficulties. Furthermore, no adequate low-cost procedure for providing trace information is currently available. The limitations of the existing solutions are likely to be exacerbated in the future as internal processor clock frequencies continue to increase.
In a conventional system, a processor discontinues execution in the debug mode and sets a stop transmit signal. An external system detects assertion of a stop and interrogates a debug port to determine the reason for termination of execution. Reasons for termination include, for example, a breakpoint, an illegal memory access, and transport of a printf() data string. The conventional system accesses a printf() data string, transfers the data string via the JTAG port, sends the printf() data string to a source-debug console, and sends a signal to the source-console designating that the command is terminated, the processor has stopped executing and the reason that execution is stopped. The processor is then enabled to begin execution and the interrupted program continues execution. Termination of execution may be suitable for debugging in kernel mode, but is generally unacceptable in application mode for many applications.
The printf() data transfer is cumbersome because the printf() command heavily intrudes into the operation of the processor. In the conventional system, entry into debug mode demands that the processor stops executing, and the debug port generates a signal indicating that the processor has stopped and the reason the processor has stopped is to deliver a printf() string. Accordingly, in the conventional system each time a printf() command is executed in the kernel mode debug or an application mode by a target system processor, the processor has to stop all ruing applications and stop execution of the kernel.
A well-known and highly critical problem with in-circuit emulation (ICE) systems is that a debug operation using ICE demands that the process executing in the target processor undergoing the debug operation must stop execution to allow examination of operating conditions and signals. Therefore, the advantage of the ICE system in allowing full control and visibility of data such as program trace data is countered by the disadvantage of stopping execution of the processor. When the processor stops, all interrupt handling stops, a highly disadvantageous condition in real-time environments such as communication and network environments.
What is needed is an apparatus and operating technique that allows a debug system full visibility and access to data, including a program trace capability, while permitting the processor, kernel software and application software to continue running while the debug data is accessed.